#!/bin/bash
# Description: Verify whether node-fetch is declared for the runtimes that import src/lib/stellar/index.ts.
set -euo pipefail

rg -n "from ['\"]node-fetch['\"]|require\\(['\"]node-fetch['\"]\\)" .

fd -t f '^(package\.json|deno\.jsonc?|import_map\.json)$' . --exec sh -c '
  echo "--- $1"
  sed -n "1,220p" "$1"
' sh {}

cat -n src/lib/stellar/index.ts

python3 - <<'PY'
import json

# Simulate the TypeScript index signature behavior
# The original: [key: string]: any
# TS Behavior: A property accessed with [string] can accept value of type 'any'.
# Replacing with 'unknown': 
#   1. The interface becomes: { [key: string]: unknown }.
#   2. Assigning an object `data` (JSON) to a variable of this type is valid (record).
#   3. The issue is `map((r: any) => r as HorizonOperation)`. 
#      If the interface has `[key: string]: any`, and data comes in, mapping `r` to `HorizonOperation` is fine.
#      If we change index to `unknown`, the variable `r` inside map (inferred from `records`) would be `unknown`.
#      `r as HorizonOperation` on `unknown` is valid.
# 4. However, the proposed fix in the original comment suggests a structural type `HorizonOperationsResponse`.
# 5. Let's verify if the specific `no-explicit-any` check flags the index signature.
#    Yes, in strict mode `any` in an index signature triggers `no-explicit-any` if it's not a workaround.

# But wait, does the map usage need fixing?
# Line 25: const ops: HorizonOperation[] = (data._embedded?.records || []).map((r: any) => r as HorizonOperation);
# If we fix line 9 to 'unknown', line 25's `(r: any)` is still an explicit `any`.
# The original comment says "lines 9-9 and 25-25".
# If index signature is `any`, it flags line 9.
# If parameter `r` is `any`, it flags line 25.

# Proposed change:
# Line 9: [key: string]: unknown; -> This is a known workaround for unknown additional props but often requires type narrowing when accessing.
# BUT, the `no-explicit-any` rule *specifically* prohibits `any`. `unknown` is the replacement.
# However, changing line 9 to `unknown` makes line 25's `r` type `unknown` (implicitly) or `any` (explicitly).
# The proposed fix in the original comment adds an interface structure for better typing.

# Let's check if the proposed fix is better practice.
# Current: `[key: string]: any` allows everything.
# Better: `Record<string, unknown>` or specific types.
# The code uses `r as HorizonOperation`. If `data._embedded.records` has `unknown` entries, we still need to cast or verify.
# The `any` on index signature is definitely a lint violation if `no-explicit-any` is on.
# The `any` on the map parameter `r` is ALSO a lint violation.

# Conclusion: The issue is real on both lines.
# Line 9: `[key: string]: any` -> Replace with `Record<string, unknown>` or `[key: string]: unknown`.
# Line 25: `r: any` -> Remove the type annotation and let TS infer `unknown` from the array, or use the cast directly.
# The original comment suggests `[key: string]: unknown` and updating the response type.

# I will rewrite the comment to include both fixes (line 9 and 25) clearly.
print("Verification complete: Both line 9 and 25 contain explicit 'any' triggering lint rules.")
PY

cat -n supabase/functions/activity_scanner/index.ts

cd /workspace/supabase/functions/activity_scanner
cat -n index.ts

cat -n "supabase/functions/activity_scanner/index.ts"

cat -n "src/lib/supabase/admin.ts"

python3 - <<'PY'
import json

# Simulating Supabase client response for select().eq()
# If query fails (e.g., network issue, permission denied, DB error), 
# the standard supabase-js response is: error != null, and data is null.
# If query succeeds but finds no rows, response is: error == null, data == [].

# Current Code Logic at lines 10-11:
#  const { data: accounts } = await supabase.from('monitored_accounts').select('*').eq('active', true);
#  if (!accounts) return { processed: 0 };

# Scenario 1: Query FAILED (e.g., 500 error)
# Response: { data: null, error: { message: '...', ... } }
# Variable accounts = null
# if (!accounts) is TRUE -> Returns { processed: 0 } silently.
# CONSEQUENCE: The caller (e.g., Scheduled Function) sees success but 0 processed. 
# An outage is masked as "nothing to do".

# Scenario 2: Query SUCCESS, no active accounts
# Response: { data: [], error: null }
# Variable accounts = []
# typeof [] is "object", ![] is FALSE.
# Loop `for (const acct of accounts)` iterates 0 times.
# Returns { processed: 0 } explicitly.
# CONSEQUENCE: Correctly reflects "no work done".

# The bug is specific to Scenario 1 (Error vs No Results).
# The proposed fix in the original comment checks for `accountsError` explicitly.

# Let's verify if the file has any import for `SupabaseResponse` type or similar 
# to see if error destructuring is expected elsewhere.
# We also need to confirm if the current code throws on error or swallows it.

print("Analysis Result:")
print("The current code destructures ONLY `data`.")
print("When Supabase query fails, `data` is `null`.")
print("The check `if (!accounts)` treats `null` (error) and potentially other falsy values identically to 'no data'.")
print("However, if the query returns an empty array (success), `data` is `[]`.")
print("'!' converts `[]` to `false`, so `if (!accounts)` is FALSE for empty results.")
print("Wait, let's re-verify JS truthy/falsy.")
print(f"Boolean({[]}): {bool([])}") # This is True (Objects are truthy)
# Actually `![]` is false. So `if (!accounts)` with accounts=[] is FALSE.
# The code proceeds to `for (const acct of [])` which does nothing.
# It returns `{ processed: 0 }` at the end. That is fine.

# But for Error: accounts = null. `!null` is True.
# Code returns `{ processed: 0 }` immediately. 
# Error is ignored. No alerting, no propagation.

# Conclusion: The original review comment is correct. 
# The missing error check swallows database failures.
PY

node - <<'JS'
// Verify the truthiness of an empty array in JavaScript
const emptyArr = [];
console.log("Boolean([]):", Boolean(emptyArr));
console.log("![]:", !emptyArr);
console.log("Type of []:", typeof emptyArr);

// Verify the logic of the current code
// Scenario: Query fails
const errorData = null;
console.log("\nScenario: Query Failed (data is null)");
// Simulating: const { data: accounts } = { data: null, error: ... };
const accountsErrorCase = errorData;
if (!accountsErrorCase) {
  console.log("-> Current: Treates as 'no work', returns { processed: 0 }");
} else {
  console.log("-> Current: Proceeds to loop");
}

// Scenario: Query succeeds, no rows
const successData = [];
console.log("\nScenario: Success, empty results (data is [])");
console.log("Current check '!successData':", !successData);
if (!successData) {
  console.log("-> Current: Treats as 'no work'");
} else {
  console.log("-> Current: Proceeds to loop");
  for (const item of successData) {
    console.log("Processing item");
  }
  console.log("-> Loop finished empty, returns { processed: 0 }");
}
JS

sed -n '18p;27p;54p' "supabase/functions/activity_scanner/index.ts"

grep -n "error" "supabase/functions/activity_scanner/index.ts"

cat -n supabase/functions/activity_scanner/index.ts

grep -r "type HorizonOperation" --include="*.ts"

grep -r "function classifyOperation" --include="*.ts" -A 5 --include="*.d.ts"

cat -n src/lib/stellar/index.ts